Namespace 的資源控管,不測試看看嗎 (´・ω・`)
還是得從 create 開始(欸
kubectl create namespace <namespace-name>
建立測試用的 Namespace:demo-01demo-02 是下一個 Demo 要用的,先當作沒看到...
apiVersion: v1
kind: ResourceQuota
metadata:
name: <自定義名稱>
namespace: <要限制的 namespace>
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
pods: 10
milliCPU
,未指定單位則為 vCPU*註1
)以圖中的設置而言,Namespace 至少會配置 1 vCPU
和 1 Gi
記憶體可用資源,但不可使用超過 2 vCPU
和 2 Gi
記憶體,且不可運行多於 10 個 Pod。
執行結果:
apiVersion: v1
kind: LimitRange
metadata:
name: <自定義名稱>
namespace: <要限制的 namespace>
spec:
limits:
- default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
max:
cpu: "500m"
memory: 1Gi
min:
cpu: "100m"
memory: 128Mi
type: Container
default
跟 defaultRequest
感覺很容易混淆。
兩者都是 建立 Container 如果沒有明確設定資源請求時
會帶入的預設值,但意義上不太一樣:
先把設定值建立上去:
然後建立一個沒有預先設定資源值的 Pod:
再來確認看看 Pod 裡面的值(記得要下 --namespace
指令):
kubectl describe pod demo-pod --namespace=demo-01
可以看到資源預設值自動被配置上去了 ( ´ ▽ ` )ノ
再來試試看建立一個超過資源限制的 Pod:
因為自動帶入預設值: cpu limit: 500m 而建立失敗。
既然... 是因為... 有帶入預設值上限才建立失敗,
試試看不就知道了 (⁎⁍̴̛ᴗ⁍̴̛⁎)
這是因為
default
跟defaultRequest
都只針對未指定資源配置的 Container 做限制,如果自行定義就不受這兩個設定影響囉!
(但還是不能超過 ResourceQuota 的設定用量啦)
如果覺得只控制 Namespace 總量範圍太大,Container 又只有預設好像不太夠,想強行限制 Container 可以嗎?
可以的!
使用 LimitRange 的另外兩個設定值:
調整一下 LimitRange 設定值:
apiVersion: v1
kind: LimitRange
metadata:
name: <自定義名稱>
namespace: <要限制的 namespace>
spec:
limits:
- default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
max:
cpu: "500m"
memory: 1Gi
min:
cpu: "100m"
memory: 128Mi
type: Container
再次建立就會因為 cpu 上限是 500m 而建立失敗了:
ResourceQuota 和 LimitRange 都是屬於 Namespace 層級的設定,並各自針 Namespace 和 Pod/Container 做資源限制,彼此相輔相成,同時使用可以更加精確的控管 Kubernetes 的資源使用。
ResourceQuota 只針對 Namespace 總資源做控制, LimitRange 專注於 Namespace 中資源控管,除了文中的 Pod、Container,其實也可以對 PersistentVolumeClaim 做限制喔!
*註1
終止狀態
Status | Description |
---|---|
Succeeded | Pod 中的所有 Container 都成功終止,且不會重新啟動 |
Failed | Pod 中至少有一個 Container Exit Code 不為 0 或被系統終止 |
Unknown | 由於某些原因無法獲取 Pod 的狀態,通常是與 Pod 所在節點通信出現問題 |
非終止狀態
Status | Description |
---|---|
Pending | Pod 已經由 Kubernetes 系統處理中,但 Container(s) 尚未建立完成的狀態 |
Running | Pod 已經綁定到 Node 上,且 Pod 中所有的 Container 都已被建立。至少有一個容器正在運行,或者正處於啟動或重啟狀態。 |
ContainerCreating | Container 正在建立中,通常是在下載 image 或設置環境。 |
CrashLoopBackOff | Container 退出,Kubernetes 正在將它重啟。通常是應用程序錯誤或配置問題導致。 |